HTTP/2 is a new version of the HTTP protocol currently being specified by the IETF (see HTTP version 2, Internet draft dated Feb. 13, 2014, available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-10).
It is well-known that the HTTP protocol allows a client device and a server device to communicate through the exchange of requests and responses.
Conventionally, requests are sent by the client device to the server device, which in return, sends responses.
As defined by the IETF, the HTTP requests and responses are transmitted over a TCP connection established between the client and server devices.
The earliest versions of HTTP relied on different TCP connections to respectively convey each pair of (request, response).
The most recent versions of HTTP allow reusing the same TCP connection to exchange a plurality of pairs of (request, response).
In the particular case of HTTP/2, one and the same TCP connection is used between the client and server devices to exchange all the requests and responses. This makes it possible for HTTP/2 to multiplex requests and responses and even to intermingle parts of them. For instance, the client device may start sending a first request, then sends a second request, and then finishes sending its first request. On the other side, the server device may respond to the requests from the client device in any order, for example by intermingling parts of different responses.
To handle efficiently each pair of request and response, and thus to allow efficient multiplexing, HTTP/2 uses a stream identifier (ID), usually a 31-bit integer value, to identify each of the pairs. A stream can be seen as a bidirectional channel between the client and server devices used to exchange one request and the corresponding response in the established TCP connection.
Each time a new request is sent by the client device, a new stream is created. The request is sent through one or more HTTP/2 frames as defined in the above publication, each of them storing the corresponding stream ID in its frame header. The above multiplexing thus consists in multiplexing such HTTP/2 streams within the same TCP connection.
A stream is usually closed once the response associated with a given request has been received by the client device that originated said request. The closure of the stream means that the stream ID is made available for a new request/response exchange.
Since the stream is provided for a single request and the corresponding response, the words “stream” and “request” or “stream” and “response” are indifferently used in the description below because the processing of a request/response by any of the client and server devices means the same as the processing of the corresponding stream by the same device.
Be HTTP/2 or any other protocol where a plurality of requests and responses can be sent in parallel within one and the same connection, the way, and more particularly the order in which, the server device processes the plurality of requests received through the same connection is an issue for the client device. This is because the latter may desire that some requests be processed in priority compared to other requests.
HTTP/2 introduces priorities to the requests for the client device to specify such order or at least to try to drive the server device to process some requests in priority. To do so, the client device may specify a priority parameter value within a frame used to create a new stream, known as HEADERS frame, or within a frame, known as PRIORITY frame, that can be sent at any time for an existing stream to dynamically modify priorities of pending requests.
Several mechanisms for prioritization have been proposed and are described with details below.
For example, in the above publication, a 31-bit priority parameter integer value is provided with 0 representing the highest priority and 2^31−1 representing the lowest priority (or vice versa). The priority parameter integer value expresses the relative priority of a stream (or a request). The server device can use (but this is not mandatory) this information to preferentially allocate some of its resources to process a given request.
However, explicitly setting the priority parameter integer value for a request does not guarantee any particular processing or transmission order for the request and corresponding response relative to any other stream. Nor is there any mechanism provided by which the client device of a request can force or require the server device to process concurrent requests of the same connection in a particular order.
Since the priority as currently known in HTTP/2 and other protocols where a plurality of requests and responses can be sent in parallel within one and the same connection only expresses the priority of a request relatively to the priorities of other pending requests (i.e. the processing of the request depends on other priority parameter values associated with the other requests), the client device lacks control over the server device, in particular regarding the scheduling and processing of responses by the latter.
For example, the behaviour of the server device when handling a request may somehow differ from what is expressed by the priority parameter value associated with the request. For instance, the server device may start sending data (response) relating to low priority requests because the data are readily available in a front-end cache, while the data for highest priority requests need to be requested from a backend which thus needs to compute them.
The present invention has been devised to address at least one of the foregoing concerns.